This PR introduces the option to make "Lint commits" job optional.

In repositories where the "squash and merge" strategy is used for merging pull requests, commits are squashed in every branch after merge.
Linting commits that in main are lost after the PR has been merged is not very useful.

The change is backwards compatible, because by default "Lint commits" continues to run as it does currently.

Checklist before requesting a review

• I have performed a self-review of my code
• Does the code follow the team's coding standards and best practices?
• Is the code well-organized and easy to understand?
• Are file, variable and function names clear and meaningful?
• Are there any duplicated code blocks that can be refactored into reusable functions?

Functionality

• Does the PR implement the intended functionality or fix the issue described in the title and description?
• Are there any edge cases that have been overlooked?

Testing

• Are there sufficient tests covering the changes?
• Are there any missing test cases that need to be added?
• Has the code been tested in different environments if applicable (e.g., browsers, platforms, devices)?

Documentation

• Are the changes well-documented and easy to understand?
• Are there any missing or outdated comments in the code?
• Is the PR title clear and detailed enough to provide necessary context?

Performance

• Do the changes have any impact on the system's performance?
• Are there any potential bottlenecks that need to be addressed?

Dependencies

• Have the changes introduced any new dependencies or updated existing ones?
• Are the dependencies up-to-date and secure?

Compatibility

• Will the changes have any adverse effects on other parts of the system?
• Do they work well with other existing features?

Continuous Integration/Deployment (CI/CD)

• Have the changes passed the CI/CD pipeline?
• Are there any deployment considerations or steps that need to be taken into account?

Code Review language

• Is the feedback provided in a constructive and respectful manner?
• Has the reviewer avoided personal attacks or harsh language?
• Are there any suggestions for improvement or alternative approaches?